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Abstract 

Sorting algorithms are an intrinsic part of functional programming 
folklore as they exemplify algorithm design using folds and un¬ 
folds. This has given rise to an informal notion of duality among 
sorting algorithms: insertion sorts are dual to selection sorts. Using 
bialgebras and distributive laws, we formalise this notion within a 
categorical setting. We use types as a guiding force in exposing the 
recursive structure of bubble, insertion, selection, quick, tree, and 
heap sorts. Moreover, we show how to distill the computational 
essence of these algorithms down to one-step operations that are 
expressed as natural transformations. From this vantage point, the 
duality is clear, and one side of the algorithmic coin will neatly lead 
us to the other “for free”. As an optimisation, the approach is also 
extended to paramorphisms and apomorphisms, which allow for 
more efficient implementations of these algorithms than the corre¬ 
sponding folds and unfolds. 

Categories and Subject Descriptors D.1.1 [Programming Tech¬ 
niques]: Applicative (Functional) Programming; F.2.2 [Analysis 
of Algorithms and Problem Complexity]: Nonnumerical Algo¬ 
rithms and Problems—Sorting and searching 

General Terms Algorithms, Languages 

1. Introduction 

Sorting algorithms are often the first non-trivial programs that are 
introduced to fledgling programmers. The problem of sorting lends 
itself to a myriad of algorithmic strategies with varying asymptotic 
complexities to explore, making it an ideal pedagogical tool. Within 
the functional programming community, the insertion sort also 
serves to exemplify the use of folds, where the key is to define an 
appropriate function insert which inserts a value into a sorted list. 

insertSort :: [Integer ] —> [Integer] 
insertSort = foldr insert [ ] 

The insertion function partitions a given list into two using an 
ordering of its elements with respect to the value to be inserted. 
This value is then inserted in between the partitions: 

insert:: Integer —>• [ Integer] —> [Integer] 
insert y ys = xs -t+ [y ] 4P zs 

where ( xs,zs) = partition ( <y ) ys 


[Copyright notice will appear here once ’preprint’ option is removed.] 


This is an entirely routine and naive definition, which makes use of 
the partition function from the list utilities section of the Haskell 
Report. When the input list ys is ordered, insert y ys adds y to the 
list ys and maintains the invariant that the ensuing list is ordered. 
Thus, we are able to fold an unordered list into an ordered one when 
we start with an empty list as the initial value of the fold. 

Perhaps less well known is that an alternative sorting algorithm, 
selection sort, can be written in terms of an unfold. An unfold can 
be thought of as the dual of a fold: a fold consumes a list, whereas 
unfold produces a list, as evident in the type of unfoldr: 

unfoldr:: ( b —> Maybe ( a,b )) —>■ —>■ [a] 

A selection sort constructs an ordered list by repeatedly extracting 
the least element from an unordered list. This effectively describes 
an unfold where the input seed is an unordered list that is used to 
produce an ordered list: 

selectSort :: [Integer] —> [Integer] 
selectSort = unfoldr select 

The function select removes the least element from its input list, 
and returns that element along with the original list with the ele¬ 
ment removed. When the list is empty, the function signals that the 
unfolding must finish. 

select:: [Integer] —> Maybe ( Integer , [Integer]) 
select [ ] = Nothing 
select xs = Just (x,xs') 
where x = minimum xs 
xs' = delete x xs 

With a little intuition, one might see that these two sorting al¬ 
gorithms are closely related, since they fundamentally complement 
one another on two levels: folds dualise unfolds, and insertion du¬ 
alises selection. However, the details of this relationship are some¬ 
what shrouded by our language: the connection between the in¬ 
gredients of insert and select is difficult to spot since append and 
partition seem to have little to do with minimum and delete. Fur¬ 
thermore, the rendition of insert and select in terms of folds and 
unfolds is not straightforward. 

In order to illuminate the connection, we use a type-driven ap¬ 
proach to synthesise these algorithms, where notions from category 
theory are used to guide the development. As we shall see, naive 
variants of insert and select can be written as an unfold and fold, 
respectively, thus revealing that they are in fact dual. As a conse¬ 
quence, each one gives rise to the other in an entirely mechanical 
fashion: we effectively obtain algorithms for free. We will obtain 
the true select and insert with alternative recursion schemes. 

Of course, both of these algorithms are inefficient, taking 
quadratic time in the length of the input list to compute, and 
in practice these toy examples are soon abandoned in favour of 
more practical sorting algorithms. As it turns out, our venture into 
understanding the structural similarities between insertSort and 
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selectSort will not be in vain: the insights we shall gain will be¬ 
come useful when we investigate more efficient sorting algorithms. 
The main contributions of the paper are as follows: 

• A type-driven approach to the design of sorting algorithms us¬ 
ing folds and unfolds, which we then extend to paramorphisms 
and apomorphisms in order to improve efficiency. 

• An equivalence of sorting algorithms, which allows us to for¬ 
malise folkloric relationships such as the one between insertion 
and selection sort. 

• Algorithms for free; because the concepts we use to develop 
these algorithms dualise, each sorting algorithm comes with 
another for free. 

• As a consequence of this formalisation, we relate bialgebras 
and distributive laws to folds of apomorphisms and unfolds of 
paramorphisms. 

We continue this paper with a gentle introduction to folds, un¬ 
folds, and type-directed algorithm design in Section 2. Then, we 
delve into sorting by swapping in Section 3, defining two sorting 
algorithms at once using a distributive law with folds and unfolds. 
In Section 4, we introduce para- and apomorphisms and use them 
to define insertion and selection sort in Section 5. We move on 
to faster sorting algorithms in Section 6 (quicksort) and Section 7 
(heapsort). Finally, we review related work in Section 8, and con¬ 
clude in Section 9. 


2. Preliminaries 

The standard definitions oifoldr and unfoldr in Haskell obscure the 
underlying theory that gives us these recursive schemes because 
they are specialised to lists; these schemes in fact generalise to a 
large class of recursive datatypes. Here, we give an alternate pre¬ 
sentation of recursive datatypes, folds, and unfolds, that provides 
a more transparent connection to the theory presented in this pa¬ 
per. For this and subsequent sections, we assume a familiarity with 
folds, unfolds, and their characterisation as initial algebras and final 
coalgebras. We have otherwise attempted to keep the categorical 
jargon light, giving brief explanations where necessary. 

Folds, also called catamorphisms, provide a recursion scheme 
for consuming a data structure by combining its elements to pro¬ 
duce a value. The idea is that the recursion scheme follows the 
shape of the data structure, and the details of combining the ele¬ 
ments are given by the functions that replace the constructors. To¬ 
gether, these functions constitute the algebra of the fold. 

It is possible to define recursive datatypes in such a way that the 
definition of fold shows this connection more transparently than 
the usual Haskell definition. To do this, we introduce the view of 
recursive datatypes as fixpoints. First, the type 

newtype jut/ = In {in° ::/ (p /)} 

takes a functor to its least fixed point. When used in a point-free 
manner. In will be written as in, but In a will be written as [a]. As 
an example of building a recursive datatype, consider the functor 

data List list = Nil \ Cons K list 

where we use K to represent some ordered key type. Note that we 
deliberately introduce lists that are not parametric because this sim¬ 
plifies the exposition, and parametricity with type class constraints 
can be reintroduced without affecting the underlying theory. As its 
name suggests, this datatype is similar to that of lists with elements 
of type K. In this case, however, the recursive argument to Cons 
has been abstracted into a type parameter. We call such a datatype 
the base functor of a recursive datatype, and the functorial action 
of map marks the point of recursion within the datatype: 


instance Functor List where 
mapf Nil = Nil 
map f (Cons kx) = Cons k(f x) 

We then tie the recursive knot by taking the least fixed point p List, 
which represents the type of finite lists with elements of type K. 
In a category theoretic context, (juF, in) is the initial algebra of the 
functor F. 

Now that datatypes and algebras are to be defined in terms of 
base functors, it is possible to give a generic definition of fold: 
fold:: (Functor f) =>(/a —> a) —> pf —> a 
foldf=f map (foldf)-in° 

This definition oifold only depends on the base functor; this deter¬ 
mines the type of the algebra, the shape of the data structure, and 
the recursive pattern over it (via the definition of map). One of the 
impacts of such a relationship is that the control flow of any pro¬ 
gram written as a fold matches the data structure. Assuming that the 
running time of an algebra is constant, this means that the running 
time of a fold is always linear in the size of input. Such a property 
can be a powerful guarantee, but also an onerous requirement when 
the control flow of an algorithm does not precisely match the data 
structure, as we will show. Note that our cost model will assume 
that Haskell is strict in order to avoid the additional complexity of 
lazy evaluation. We will continue in this manner, as such issues are 
not relevant to any of our discussions. 

As a short example of the type-directed approach that we will 
follow again and again, we point out that we can write in° :: pF — > 
F (p F) in terms of in. It is a function from ju F, so we should try 
a fold: we simply need an algebra of type F (F (pF)) —> F (juF). 
An obvious candidate is map in, so in° =fold (map in): we will see 
this again at the end of the section. 

Dual to folds are unfolds, also known as anamorphisms, which 
provide a scheme for producing a data structure instead of con¬ 
suming one. This requires the dual view of recursive datatypes as 
greatest fixed points of functors, which is defined as 
newtype vf = Ouf {out::f (v/)} 

When used in a point-free manner, Ouf will be written as ouf, 
but Ouf a will be written as \_a\. Using the base functor List, vList 
also ties the recursive knot, and represents the type of indefinite 
lists. However, instead of algebras and folds, we are now concerned 
with coalgebras and unfolds. A coalgebra is a function b —> List b, 
where b is the type of the seed value. As the categorical dual of an 
initial algebra, (vF ,out) is the final coalgebra of the functor F. 

We can now define unfold in the same manner as fold, where 
the details of the recursive scheme depend only on the base functor 
of the datatype being produced: 

unfold :: (Functorf) => (a —>f a) —¥ (a —> vf) 
unfoldf = ouf ■ map (unfoldf) •/ 

Again, the placement of the recursive calls is determined by the 
definition of map. As with folds, the control flow of unfolds is 
determined by the base functor (and therefore the shape of the data 
structure). In this case, this means that, given a coalgebra with a 
constant running time, the running time of an unfold is linear in the 
size of the output. As with folds, this is an important fact to keep in 
mind in subsequent sections. 

We can again use a type-directed approach to express ouf :: 
F (vF) — i vF in terms of out. It is a function to vF, so this time 
we should try an unfold. As one would expect from duality, ouf = 
unfold (map out). 

Because the type declarations for the fixed points of functors 
were given in Haskell, the difference between greatest and least 
fixed points is not obvious; the definitions are the same except 
for the names of the constructors and destructors, and these two 
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datatypes are isomorphic, a property known as algebraic compact¬ 
ness. While this is the case for Haskell, it is not true in general 
and we do not depend on this. We will therefore be explicit about 
whether we are working with pF or vF by using different types. 
We will also be explicit when we move from vF to pF by using 
downcast :: (Functor f) =>vf^pf 
downcast = in ■ map downcast ■ out 
We can always go the other way and embed the least into the 
greatest with a function upcast:: (Functorf) => pf —> v/. How can 
we define upcast ? Let us first discuss a small generalisation: given 
the concrete base functors F and G, how can we write a function 
of type pF —► vG? We will follow a type directed approach; it is a 
function from p F, so we can write it as a fold: 
fold (unfold c) : pF —t vG 
unfold c : F (vG) — ¥ vG 

c : F (vG) —>■ G (F (vG)) 

— F (G (vG))-> G (F (vG)) 

In fact, it is a fold of an unfold. (The types on the right progress 
from top to bottom, the terms of the left are built from bottom to 
top.) Alternatively, upcast is a function to vG, so we can write it as 
an unfold: 

unfold (fold a) : pF —> vG 

fold a : jUF —> G (pF) 

a : F (G (pF)) -* G (pF) 

= F (G (pF)) -A G (F (pF)) 

This time it is an unfold of a fold. In both cases, we have gone 
one step further and expanded the recursive types so that we could 
reveal that the type of the coalgebra c is almost the same as the 
type of the algebra a. This suggests that a and c are both instances 
of some function s:: F (G x) —> G (F x) that is parametric in x. We 
will revisit this idea in the next section. 

Now to define upcast: it is a specialisation of the above case, 
so we need either an algebra F (F (juF)) —> F (juF) or a coalgebra 
F(vF)—>■ F (F (vF)). We have seen these before when defining in° 
and ouf: the former is simply map in, and the latter map out. 
upcast :: (Functorf) => pf -a vf 
upcast = fold (unfold (map out)) = fold ouf 
= unfold (fold (map in)) = unfold in° 

Why are these equal? We will see why in the next section. 

3. Sorting by Swapping 

With the preliminaries of folds and unfolds in place, we now turn 
our attention back to sorting algorithms. First, we start by creating 
a new datatype to represent the base functor of sorted lists: 
data List list = Nil \ Cons K list 
instance Functor List where 
mapf Nil = Nil 

map f ( Cons k list) = Cons k (f list) 

Note that List is defined exactly like List, but we maintain the 
invariant that the elements in a List are sorted. Our goal is to express 
sorting algorithms as some function sort, with the following type: 
sort::pList -a v List 

This precisely captures the notion that we will be consuming, or 
folding over, an input list in order to produce, or unfold into, an 
ordered list. This choice of type is motivated by the fact that there 
is a unique arrow from an initial object, in this case pList, and there 
is a unique arrow to a final object, in this case v List . 


In Section 1, we wrote selection sort as an unfold. Let us replay 
this construction, but now with the definitions from Section 2 and 
following our type directed theme. What we obtain is not the true 
selection sort, but bubble sort: 

bubbleSort :: pList -a v List 
bubbleSort = unfold bubble 
where bubble =fold bub 
bub:: List ( List (pList)) —¥ List (pList) 
bub Nil = Nil 

bub (Cons a Nil) = Cons a \Nit\ 
bub (Cons a ( Cons bx)) 

| aO = Cons a \Consbx 1 
| otherwise = Cons b \ Cons a x] 

This is because the select operation should select the minimum 
element but leave the remaining list unchanged. Instead, fold bub 
produces the swapping behaviour seen in bubble sort. Since bub is 
a constant-time operation, bubble sort is a quadratic-time algorithm 
(the input and the output list have the same length). 

We also wrote insertion sort as a fold. If we write it as a fold of 
an unfold, we obtain a naive version of insertion sort. 

naivelnsertSort :: pList —> v List 
naivelnsertSort =fold naivelnsert 
where naivelnsert = unfold naivelns 
naivelns:: List (vList) -A List (List (vList)) 
naivelns Nil «= Nil 

naivelns (Cons a \ Nil \ ) = Cons a Nil 
naivelns (Cons a \ Cons b x\) 

|aO 'A Cons a (Cons b x) 
j otherwise jg= Cons b (Cons a x) 

Why have we labelled our insertion sort as naive? This is because 
we are not making use of the fact that the incoming list is ordered— 
compare the types of bub and naivelns. We will see how to capi¬ 
talise on the type of naivelns in Section 5. 

Our bub and naivelns are examples of the abstract algebra a and 
coalgebra c that we discussed at the end of the previous section. 
As pointed out then, the similarities in the types are plain to see, 
but another observation now is that the implementations of bub 
and naivelns are almost identical. The only difference is that ["-] 
appears on the left in bub, and |_-J appears on the right in naivelns. 
At the end of the previous section, we suggested that there must 
be some parametric function that generalises both the algebra and 
coalgebra. As bubble and naive insertion sorts are swapping sorts, 
we will call this function swap. 

swap:: List ( List x) -a List (List x) 
swap Nil = Nil 

swap (Cons a Ml) = Cons a Nil 
swap (Cons a ( Cons b x)) 

| a^b == Cons a (Cons bx) 

| otherwise = Cons b (Cons a x) 

This parametric function extracts the computational ‘essence’ of 
bubble and naive insertion sorting. It expresses the core step: swap¬ 
ping adjacent elements. We have initially referred to it as paramet¬ 
ric, but in a categorical setting we will consider it natural in x. Fur¬ 
thermore, we will read its type as a so-called distributive law —it 
distributes the head of a list over the head of an ordered list. 

Given swap, how do we turn it back into bub and naivelns ? For 
the former, we match the return type of swap. List (List (pList)), 
to the return type of bub List (pList) using map in. Dually, we 
match the input type of naivelns with the input type of swap using 
map out. So our final sorting functions become: 
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bubbleSort 1 :: pList —t v List 
bubbleSort 1 = unfold {fold (map in ■ swap)) 
naive Insert Sort 1 :: uList —» v List 
naivelnsertSori = fold (unfold {swap-map out)) 

Now that we can express bub as map in ■ swap, and naivelns as 
swap ■ map out, we would like to dig deeper into the apparent 
relationship between the two. 

3.1 Algebra and Coalgebra Homomorphisms 

Let us proceed towards this goal by first looking at a property 
of bubble. Recall that an F-algebra homomorphism between F- 
algebras a :: F A —> A and b :: F B —> B is a function with the property 
fa = b- mapf —F-coalgebra homomorphisms have the dual prop¬ 
erty. We originally wrote bubble as a fold of the algebra bub. The 
following law states that bubble is a Zist-algebra homomorphism. 

bubble ■ in = bub ■ map bubble 

It says that bubble is a homomorphism from the initial algebra, in, 
to the algebra bub. We will render this law as a diagram, as what 
follows is more easily motivated in diagrammatic form. 


We claimed that we can replace bub with map in ■ swap, so let us 
rewrite the homomorphism law, to express the relationship between 
bubble and swap: 

bubble ■ in = bub ■ map bubble 
4=v { bub is replaceable by map in ■ swap } 

bubble ■ in = map in ■ swap ■ map bubble 
Let us also redraw the diagram with this replacement, 


replaceable by swap ■ map o\ 


along with the corresponding diagr 
to the re-arranged variant. 


Now, not only do we have a new expression of the relationships 
between bubble and swap, and naivelnsert and swap, but we can 
also begin to see the relationship between bubble and naivelnsert. 

3.2 Bialgebras 

We have drawn the dashed boxes to highlight the fact that these are 
so-called bialgebras: that is, an algebra a and a coalgebra c, such 
that we can compose them, c ■ a. In the first diagram, bubble forms 
a bialgebra {pList, in, bubble), and in the second, naivelnsert forms 
{vList,naivelnsert,out). To be precise, these are .svvap-bialgebras, 
where the algebra and coalgebra parts are related by a distributive 
law, in this case, swap. For an algebra a: List X —> X and coalge¬ 
bra c: X — > List X to be a .wap-bialgebra, we must have that 


This condition is exactly v. 
diagrams for bubble and m 


and then re-arrange it to better see the symmetry by i 
List (pList) to the left. 


I List {pList) | ma p bubble 


We now will use the theoretical framework of bialgebras to 
show that bubble sort and naive insertion sort are, categorically 
speaking, two sides of the same coin. 

We already have an understanding of initial algebras and final 
coalgebras, and we will proceed by identifying the initial and fi¬ 
nal .vvvap-bialgebras. Our initial .vvvr/p-bialgebra will he (pList, in, 
fold {map in ■ swap)) wad fold a will be the unique .uvap-bialgebra 
homomorphism to any bialgebra (X,a,c). Expressed diagrammati- 


'^ List ( pList )^ r ma P ln 

Similarly, we can express the relationship betv 
and swap. 
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There are three proof obligations that arise from this diagram. First, 
that ( pList, in,fold (map in ■ swap)) is a valid swap-bialgebra, but 
this is true by definition. Second, that the top half of the diagram (f) 
commutes, but this is true by construction. Third, that the bottom 
half of the diagram (±) commutes: 

map (fold a)-fold (map in ■ swap) = c fold a . 

Proof. We proceed by showing that both sides of the equation can 
be expressed as a single fold. 

map (fold a) -fold (map in ■ swap) = c fold a 
<=Y { c is an algebra homomorphism, see below } 

map (fold a) -fold (map in ■ swap) =fold (map a ■ swap) 
This first step is justified by the law for .sm/p-bialgebras (1), which 
states that c is an algebra homomorphism from a to map a ■ swap: 
c-a = (map a ■ swap) ■ map c . 

To conclude the proof, we need to show that map (fold a) is also an 
algebra homomorphism from map in ■ swap to map a ■ swap, 
map (fold a) ■ map in ■ swap 
= { map preserves composition } 

map (fold a-in)- swap 
= {fold a is a homomorphism } 
map (a ■ map (fold a)) ■ swap 
= { map preserves composition } 

map a ■ map (map (fold a)) ■ swap 
= { swap is natural } 

map a ■ swap ■ map (map (fold a )) 

Thus,/o/d a is the coalgebra homomorphism that makes the bottom 
half of the diagram (i) commute. □ 

We have now constructed the initial .vivap-bialgebra. We can 
dualise this construction to obtain the final .nvap-bialgebra. We take 
(v List , unfold (swap ■ map out),out) to be the final swap- bialgebra, 
and unfold c as the unique homomorphism from any bialgebra ( X, 
a, c). Again, that this is a valid bialgebra is by definition, and that 
unfold c is a coalgebra homomorphism is by construction. The 
third proof obligation, that unfold c is an algebra homomorphism, 
follows from the dual of the proof: from the naturality of swap, and 
that a is a coalgebra homomorphism. 

Now that we have the theoretical framework in place, we are in 
a position to say something about the relationship between bubble 
sort and naive insertion sort. Let us remind ourselves of their 
definitions. 

bubbleSort' = unfold (fold (map in ■ swap)) 

naivelnsertSori = fold (unfold (swap ■ map out)) 

We have shown that bubble and naivelnsert are the initial and final 
.svvap-bialgebras, respectively. Because of initiality,/oW naivelnsert 
is the unique arrow from bubble. Dually, because of finality, the 
unique arrow to naivelnsert is unfold bubble. 

List (pList) -> List (v List ) 

in naivelnsert 

y fold naivelnsert y 
pList -||->• v List 

( unfold bubble 

out 

List (pList) ->■ List (v List ) 


By uniqueness, bubbleSort 1 and naivelnsertSori! are equal, and 
with that we have arrived at our first result. 

We need to be precise about what we mean by “equal”. This 
equality is more than merely extensional: indeed, all the sorts in 
this paper are extensionally equal as they correctly sort a list. Our 
achievement is twofold. 

First, we have distilled the computational essence of insertion 
into a list, and selection from a list, down to a function swap ; we 
read it as a distributive law that describes a single step of both of 
these sorting algorithms. 

Second, given a distributive law such as swap, there are two 
ways to turn it into a sorting function, pList —> v List : as a fold of 
an unfold, and an unfold of a fold. While these mundanely construct 
the recursive computation, this is truly where the duality arises. In 
the case of swap, the former is naive insertion sort and the latter is 
bubble sort. Moreover, using the framework of bialgebras we can 
set up the former as the initial construction, and the latter as the 
final construction. There is a unique arrow from initial to final, and 
our two sorting algorithms are simply dual ways of describing it. 

4. Para- and Apomorphisms 

In the previous section, we have seen how to write insertion sort 
naively as a fold of an unfold, and bubble sort as an unfold of a 
fold. While simple, these algorithms are inefficient: fold traverses 
the list linearly, applying the algebra to each element. Since our 
algebras are unfolds, the running time is quadratic in length of the 
list. Dually, the same holds for unfold with coalgebras that are folds. 

At this stage, the novice functional programmer is typically in¬ 
troduced to other sorting algorithms with better asymptotic com¬ 
plexity. However, to write the swapping sorts that we have seen 
thus far in terms of primitive recursive morphisms, we need variants 
of our cata- and anamorphisms, namely para- and apomorphisms. 
Apomorphisms allow us to write more efficient coalgebras that can 
signal when to stop corecursion, and paramorphisms provide a way 
to match on the intermediate state of the list during computation. 

4.1 Paramorphisms 

Paramorphisms are a variation of catamorphisms—folds—where 
the algebra is given more information about the intermediate state 
of the list during the traversal. By analogy with catamorphisms, we 
call the argument to a paramorphism an algebra, though this is not 
strictly accurate. In a catamorphism, the algebra gets the current 
element and the result computed so far; in a paramorphism, the 
algebra also gets the remainder of the list. This extra parameter can 
be seen as a form of an as-pattem and is typically used to match on 
more than one element at a time or to detect that we have reached 
the final element. 

For the paramorphism algebra we will need products and a split 
combinator that builds a product from two functions: 
data axb = As{outl::a, outr ::b} 

ft)->(*-> ax*) 

(fAg)x = As(fx) (gx) 

We will write the constructor of products. As a b, as a=:b (which 
should be read as the Haskell as-pattem: a@b). 

We are now ready to define the paramorphism: 
para :: (Functorf) => (f (pf x a) -4 a) -4 (pf -4 a) 
paraf = f ■ map (id A paraf) ■ in° 

Note the similarity with fold (Section 2); the important difference 
is in the type of the algebra, which is now f (pf x a) — > a instead 
of just f a — > a. In fact, para can be defined directly as a fold: 
para 1 :: (Functorf) => (f (pf x a) -4 a) -4 (pf -4 a) 
para! f = outr fold ((in ■ map outl) A/) 
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Another name often given to para is recurse (Augusteijn 1999). 

4.2 Apomorphisms 

Having seen how to construct the paramorphism, we now pro¬ 
ceed to its dual: the apomorphism. Apomorphisms generalise 
anamorphisms—unfolds—and can be used to provide a stopping 
condition on production, which in turn improves the efficiency of 
the algorithm. Also by analogy, we will refer to argument to an 
apomorphism as a coalgebra. 

For defining apomorphisms we will need a disjoint union type 
and a combinator that destructs a sum using two functions, imple¬ 
menting a case analysis: 

data a + b = Stop a \ Play b 

(V 

(/Vg) {Stop a) =f a 
(fVg) (Playb ) =gb 

We name the constructors of +, Stop and Play, alluding to their 
behaviour in the context of a coalgebra. We write Stop a as a*, and 
Play b as *b. 

We are now ready to define the apomorphism: 
apo ;; {Functorf) > {a -4/ (vf+a)) -4 (a 4- v/) 
apof = ouf ■ map {id. V apof) f 

As expected, apo is similar to unfold, but the corecursion is split 
into two branches, with no recursive call on the left. Another name 
often given to apo is corecurse. 

Apomorphisms can also be defined in terms of unfolds. How¬ 
ever, this is not as efficient: recursion continues in ■ mode, copying 
the data step-by-step: 

apo' ;; {Functorf) => {a —>f {vf+a)) —> {a —> vf) 
apo'f = unfold {{map (■) • out) V/) • ► 

At the end of Section 2, we followed a type-directed approach 
to derive the types of an algebra a and a coalgebra c in the terms 
fold {unfold c) and unfold {fold a). We will now repeat this ex¬ 
ercise for a and c, but this time with the terms fold {apo c) and 
unfold {para a). 

fold {apo c) : pF —> vG 
apo c : F (vG) -4 vG 

c : F (vG) - 4 - G (vG + F (vG)) 

— F (G (vG)) -4 G (F + (vG)) 

unfold {para a) : pF -4 vG 

para a : pF —>■ G (pF) 

a : F {pF x G (pF)) -4 G (ftF) 

— F (G x (/tF)) -4 G (F ()tF)) 

By introducing the types, 
ty P e/+ a = a +f a 
type/ x a = axfa 

we can see that the algebra a and a coalgebra c are still closely 
related. While the correspondence is no longer as obvious as in 
Section 2, we will see that we can describe both a and c in terms of 
a natural transformation of type FoG x —>GoF. 

An obvious question is why we do not use a para of an apo, or 
an apo of a para. The answer is simply that we lose the relationship 
between a and c: we cannot construct a natural transformation that 
relates the two. 

para {apo c) : pF —> vG 

apoc : F (;UF x vG)-1 vG 


c : F {pF x vG) -4 G (vG + F (juF x vG)) 

apo (para a) : pF —> vG 

para a : pF -r G (vG + pF) 

a : F(pFxG(vG + pF))->G(vG+pF) 
While expressive, these types are not useful to us. 


5. Insertion and Selection Sort 

The naive insertion sort presented in Section 3 is unable to leverage 
the fact that the list being inserted into is already sorted, and so it 
continues to scan through the list, even after the element to insert 
has been placed appropriately. Now that we have apomorphisms, 
however, we can write the insertion function as one that avoids 
scanning needlessly: 

insertSort :: pList -4 v List 
insertSort =fold insert 
where insert = apo ins 

The coalgebra ins is now enriched with the ability to signal that the 
recursion should stop. 

ins v.List (v List ) —> List (v List + List (v List )) 
ins Nil = Nil 

ins (Cons a [M\ ) = Cons a ( [Nil\ ■) 
ins(Consa \&Ms bx l \) 

| a^b .=d;Consa i Cons bx'\*) 

| otherwise — Cons b (► (Consax!)) 

This signal appears in the definition of the third case, where the 
element to insert, a, is ordered with respect to the head of the 
already ordered list, so there is no more work to be done. The 
stop signal is also used in the second case, where the list to insert 
into is empty. We could have given the following as an alternative 
definition for this case: 

ins (Cons a [MZJ j =4 Cons a (► Nil ) 

While still correct, the apomorphism would take one more step, to 
turn ► Nil into Nil. With or without the superfluous step, insertSort 
will run in linear time on a list that is already sorted; this is in 
contrast to naivelnsertSort, bubbleSort, and selection sort, which 
we will define shortly. All of these will still run in quadratic time, 
as they cannot abort their traversals. Early termination in apomor¬ 
phisms avoids redundant comparisons and is the key to insertSort’s 
best and average case behaviour. 

We can extract a new natural transformation from ins. In Sec¬ 
tion 3 we called the natural transformation for swapping sorts, 
swap; we will call our enriched version swop, for swap ‘n 'stop. 

swop;; List (x x List x) —1 List (x+List x) 
swop Nil = Nil 

swop (Cons a (x^.Nil)) = Cons a (x») 
swop (Cons a (x=. (Cons bx!))) 

| a^b Cons a (jc») 

| otherwise r=, Cons b (► (Cons a x!)) 

The type makes it clear that and x* really go hand-in-hand. 

Before, we had a natural transformation. List o List -4 List o 
List; now we have one with type. List o List , -4 List o List + . In 
Section 3 we saw a diagram that described the relationship between 
naivelnsert and swap; contrast this with the relationship between 
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insert and swop in the following diagram. 

[List (vUst?( id A 0Mf ) 

List ( Ljst x (v List )) 
I swop 


insert 

v List 


List (List+ (v List )) 
' List (VIM) 'T inap (WV insert) 


Note that this diagram is not symmetric in the way that the diagrams 
were in Section 3: for example, out is matched with map (id A out), 
rather than map out. This is because swop itself is not symmetric. 
In Appendix A we briefly sketch how swop can be turned into a dis¬ 
tributive law of type List + a List x —>■ List „ o List + . This distributive 
law is unneeded here, as we will write insert directly in terms of 
swop using an apomorphism. (The proof of why this is the case is, 
again, in Appendix A.) As in Section 3, we can also dualise this de¬ 
velopment. Just as naive insertion as an unfold was dual to bubble 
as a fold, insertion as an apomorphism can be dualised to selection 
as a paramorphism. 


selectSort:: pList —> v List 
selectSort = unfold select 
where select = para sel 
sel:: List (pList x List (pList)) —> List (pList) 
sel Nil =NU 

sel (Cons a (x^Nil)) = Cons a x 
sel (Consa (x^.( Cons bx!))) 

| a ^ b = Cons ax 

| otherwise = Cons b \ Cons a x!~\ 

The sole difference between sel and bub (Section 3) is in the case 
where a ^ b: sel uses the remainder of the list, supplied by the 
paramorphism, rather than the result computed so far. This is why 
para sel is the true selection function, and fold bub is the naive 
variant, if you will. 

To conclude our discussion, we have new definitions of insertion 
and selection sort in terms of our new natural transformation, swop. 

insertSort' :: pList —» vList 
insertSort' = fold insert 

where insert = apo (swop ■ map (id A out)) 
selectSort 1 :: uList —» vList 
selectSort! = unfold select 

where select = para (map (id V in) ■ swop) 


We shall omit the proofs that select and insert form initial and 
final bialgebras, respectively; the details are lengthy and beyond 
the scope of this paper, see Hinze and James (2011). Instead we 
shall simply give the diagram that states them. 


List+ (pList) -► List+ (vList) 

id V in id \7 insert 

Y fold insert Y 

pList -||-> v List 


unfold select 


id A select^ 

List , (pList) - 


Thus, insertSort 1 and selectSort 1 are dual; moreover, by uniqueness, 
they are equal. 


6. Quicksort and Treesort 

While the reader should not have expected better, the results of 
Section 5 are still somewhat disappointing; apomorphisms have 
helped implement a small optimisation, but the worst case running 
time is still quadratic. This arises from the use of swaps in both 
selection and insertion sort—they are fundamentally bound by the 
linear nature of lists. If we are to do better than a quadratic bound, 
we need sublinear insertion and selection operations. To use such 
operations, we must introduce an intermediate data structure that 
supports them. We do this by moving to a two-phase algorithm, 
where the first phase builds such an intermediate data structure 
from a list, and the second phase consumes it to produce a sorted 
list. In this section, we seek a better sorting algorithm by using 
binary trees with elements of type K. 

data Tree tree = Empty \ Node tree K tree 
instance Functor Tree where 
mapf Empty = Empty 
mapf (Node lkr)= Node (f l) k (f r) 

Henceforth, we will write Empty as £ and Node l k r as l //k\ r. In 
this section, we will be using the tree type as a search tree, 

type SearchTree = Tree 

where all the values in the left subtree of a node are less than or 
equal to the value at the node, and all values in the right subtree are 
greater. Such a tree orders the elements horizontally, such that an 
in-order traversal of the tree yields a sorted list. 

6.1 Phase One: Growing Search Trees 

First, we start with the unfold of a fold approach. Therefore, we 
seek a fold that produces something of type SearchTree (pList). 
The idea is that the fold will create one level of the tree, where 
l//k\r contains a value k for which values in the list l are less than 
or equal to k, and values in the list r are greater than k. In other 
words, k acts as a pivot around which l and r are partitioned. 

pivot::List (SearchTree (pList)) —y SearchTree (pList) 

pivot Nil = £ 

pivot (Cons a e) = \Nit] / a\ \Nit] 

pivot (Consa(l//b\r)) 

I Consul.//b\r 

j otherwise =l//b\\Cons a r\ 

In effect, fold pivot:: pList —> SearchTree (pList) is a partitioning 
function that takes a list and returns its last element as a pivot, 
along with the two partitions of that list. At each step, the enclosing 
unfold will call this fold on each of the resulting partitions, which 
will ultimately yield the entire search tree. 

The type of pivot gives us little choice in its implementation; Nil 
will be replaced with e. Cons a £ will become a tree of one element, 
with empty lists as children. Therefore, the construction of / and r 
is determined by value of the pivot, the last element. 

As we have done before, we shall extract a natural transforma¬ 
tion from this algebra. 

sprout:: List (x x SearchTree x) — > SearchTree (x + List x) 

sprout Nil = £ 

sprout (Cons a (t^£)) = (t ■) //a\ (t ■) 

sprout (Consa (t^(l//b\r))) 

I « O = (► (Cons a /)) //b\ (r■) 

| otherwise = (/■) //b\ (► (Cons a r)) 

In Sections 3 and 5, we were operating with lists and swapped the 
elements to maintain the ordering. With trees, we must maintain 
the search tree property when inserting elements. 
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Having extracted the natural transformation, we can synthesise 
the coalgebra that is dual to pivot, 

treelns :: List ( vSearchTree ) 

—> SearchTree {vSearchTree+List ( vSearchTree )) 
treelns Nil = £ 

treelns {Cons a |ej) = (LeJ ■) fa\ (LeJ ■) 
treelns {Consa [ l//b\r\) 

I = (>(Consal))//b\(r .) 

| otherwise = (/■) //b\ (► {Cons a r)) 

which takes an element of the input list and inserts it one level deep 
into a search tree. We shall call this treelns, since, as we shall see, 
this algebra forms the first phase of a treesort. Efficient insertion 
into a tree is necessarily an apomorphisnr, because of the search 
tree property, the recursion need only go down one of the branches, 
which is not possible with an unfold. 

The derivation of treelns merits some review. We began this 
section by writing a function to partition a list around a pivot. Then, 
we turned this into a natural transformation. Now, out the other 
side, so to speak, we have another useful function, which inserts 
an element into a search tree: apo treelns '..List {vSearchTree) —> 
vSearchTree. Moreover, we got this for free. 

As before, the algebra and coalgebra can be written in terms 
of the natural transformation, so pivot = map {id V in) ■ sprout and 
treelns = sprout - map {id A out). This yields two algorithms for 
generating search trees: 

grow, grow 1 :: pList —t vSearchTree 

grow = unfold {para {map {id V in) ■ sprout)) 

grow' =fold {apo {sprout ■ map {id A out))) 

We can either recursively partition a list, building subtrees from the 
resulting sublists, or start with an empty tree and repeatedly insert 
the elements into it. 

6.2 Phase Two: Withering Search Trees 

The previous section was concerned with growing search trees. 
With these in place, we will now look at ways of flattening these 
trees into a sorted lists. 

We will start with the complement to pivot, which partitioned 
a list around a pivot. Here, we need a List -coal gebra to glue the 
partitions back together. More specifically, we need a coalgebra for 
an apomorphism, so that we can signal when to stop. 
glue:: SearchTree (v List ) 

-* List (vList + SearchTree (v List )) 
glue £ = Nil 

glue (\NU\ ffa\r) = Cons a (m) 

glue ( | Cora b l\ //a\f) - Cons b (*■ (l//a\r)) 

Note that apo glue :: SearchTree (v List ) —> v List is essentially a 
ternary version of append: it takes a left and a right sorted list, an el¬ 
ement in the middle, and glues it all together. Had we implemented 
this naively as a plain unfold, the right list would also have to be 
traversed and thus induce unnecessary copying. 

Following our established course, we can extract the natural 
transformation from this coalgebra, 

wither :: SearchTree (x x List x) —> List (x + SearchTree x) 
wither e = Nil 

wither ((l^Nil)//a\(r^_)) = Cons a (r«) 

wither ((U( Cons b l')) //a\ (r-_)) = Cons b (>(( //a\ r)) 

which captures the notion of flattening by traversing a tree and 
collecting the elements in a list. Specifically, this function returns 
the leftmost element, along with the combination of the remainder. 
We can now synthesise the algebra that is dual to glue. 


shear:: SearchTree (pSearchTree x List ( pSearchTree )) 

—> List (pSearchTree ) 
shear £ = Nil 

shear ((l^Nil) //a\(r=._)) = Cons a r 

shear ((l-(Consbl'))//a\(r-_)) = Consb \l'//a\r J 

To understand what is in our hands, let us look at the third case: a is 
the root of the tree, with l and r as the left and right subtrees; b is the 
minimum of the left subtree and /' the remainder of that tree without 
b. In which case, para shear v. pSearchTree —> List (pSearchTree) 
is the function that deletes the minimum element from a search 
tree. Thus, the fold of this flattens a tree by removing the elements 
in order. This should surprise no one: the second phase of treesort 
would surely be an in-order traversal. 

We can again define both the algebra and the coalgebra in 
terms of the natural transformation, which yields two algorithms 
for flattening a tree to a list: 

flatten,flatten':: pSearchTree —> v List 
flatten = fold (apo (wither ■ map (id A out))) 
flatten' = unfold {para (map (id V in) ■ wither)) 

6.3 Putting Things Together 

We have now constructed the constituent parts of the famous quick¬ 
sort and the less prominent treesort algorithms. The components for 
quicksort dualised to give us those for treesort, and now all that re¬ 
mains is to assemble the respective phases together. 

Quicksort works by partitioning a list based on comparison 
around a pivot, and then recursively descending into the resulting 
sublists until it only has singletons left. This is precisely the algo¬ 
rithm used to create the tree in grow, and we have simply stored the 
result of this recursive descent in an intermediate data structure. 
The flatten then reassembles the lists by appending the singletons 
together, now in sorted order, and continuing up the tree to append 
sorted sublists together to form the final sorted list. 

Dually, treesort starts with an empty tree and builds a search 
tree hy inserting the elements of the input list into it, which is 
the action of grow'. The sorted list is then obtained by pulling the 
elements out of the tree in order and collecting them in a list, which 
is how flatten' produces a list. In each, tying the two phases together 
is downcast, which is necessary because grow and grow 1 produce 
trees, but flatten and flatten! consume them. 

quicksort,treeSort:: pList —> v List 
quicksort = flatten ■ downcast ■ grow 
treeSort = flatten' ■ downcast ■ grow 1 

In the average case, quicksort and treesort run in linearithmic 
time. But, we have not succeeded in eliminating a quadratic running 
time in the worst case. We are not yet done. 

7. Heapsort 

Quicksort and treesort are sensitive to their input. Imposing a hor¬ 
izontal (total) ordering to the tree offers us no flexibility in how to 
arrange the elements, thus an unfavourably ordered input list leads 
to an unbalanced tree and linear, rather than logarithmic, opera¬ 
tions. (Of course, we could use some balancing scheme.) For this 
section we will use Heap as our intermediate data structure, 

type Heap = Tree 

where the element of a tree node in a heap is less than or equal to all 
the elements of the subtrees. This heap property requires that trees 
are vertically ordered—a more ‘flexible’, partial order. 
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7.1 Phase One: Piling up a Heap 

Now that we are accustomed to the natural transformations that de¬ 
scribe the single steps of our sorting algorithms, in this section we 
will write them first; then we will derive the algebra and coalgebra 
that make up the final and initial bialgebras, respectively. 

The type of our natural transformation, which we will call pile, 
will be the same as sprout in Section 6.1, modulo type synonyms. 
However, rather than its implementation being dictated by the 
search tree property, we have a choice to make for pile. 

pile:: List (x x Heap x) —> Heap (x+List x) 
pile Nil = £ 

pile(Consa(t^£)) = (t.)//a\(t .) 
pile(Consa(t^(l//b\r))) 

I = (► (Cons b r))//a\ (/■) 

| otherwise = (>(Cons ar))//b\(l*) 

There is no choice in the first two cases, it is solely in the third 
case, which we will now examine. We can avoid the guards if we 
use min and max —this rewrite emphasises that the structure does 
not depend on the input data. We write min as n, and max as U, so 
the third case is now rendered as: 

pile(Consa(t^(l//b\r))) 

= (>(Cons (aUb) r)) //(aUb )\(/.) 

We actually have a choice between four different steps: adding the 
maximum to the left or to the right, and swapping or not swapping 
the results (the subtrees of a heap are, in a sense, unordered). 

pile (Cons a (t-(l//b\ r))) 

= (► (Cons (a J /;) /)) // (a n b)\ (r■) 

# (r.)//(anb)\(>(Cons(aUb)l)) 

= (l.)//(aHb)\(>(Cons(aUb)r)) 

= (>(Cons (aUb) r)) //(aUb )\(/.) 

We chose the last option: we always add to the right and then swap 
left with right. By doing so, we will end up building a heap that is 
a Braun tree (Braun and Rem 1983), where a node’s right subtree 
has, at most, one element less than its left. Thus we ensure that our 
heapsort is insensitive to the input, in contrast to quick (tree) sort. 

Now that we have our natural transformation in place, it is rou¬ 
tine to turn it into a List-algebra and Heap-coalgebra. We will start 
with the latter, as this will be the expected function for heapsort. 

heaplns :: List ( vHeap ) 

—> Heap ( vHeap+List ( vHeap )) 
heaplns Nil = £ 

heaplns (Cons a |e|) = (14 "JM(14 ■) 
heaplns (Consa[l//b\r\) 

I a «£ b = (> (Cons b r)) //a\ (l ■) 

| otherwise = ( ► (Cons ar)) //b\(l ■) 

We have called it heaplns as apo heaplns :: List (vHeap) —¥ vHeap 
is the heap insertion function. Thus a fold of an apo will build a 
heap by repeated insertion. (It is instructive to compare heaplns to 
treelns in Section 6.1.) 

As an aside, we can actually do slightly better: sinking the ele¬ 
ment, b, into the right subheap, r, does not require any comparisons 
as the heap property ensures that b is smaller than the elements in r. 
One solution would be to introduce a variant of lists, List! , with a 
third constructor Cons to signal when no more comparisons are 
needed. We can then write fold (apo heaplns ') • toList', where, 

heaplns' (Cons a [l //b\ r\) 

| a^b = (>(Cons<br))//a\(l.) 


heaplns' ( Cons < a _l//b\r\) 

(>(Cons<br))//a\(t*) 

All that is left is to examine the List-algebra that arises from pile. 
It is related to the pivot function in Section 6.1. There, we were 
building two lists partitioned around a pivot, but here we are select¬ 
ing the least element and collecting the rest into two lists. We shall 
name the synthesised algebra divvy, meaning to divide up. 

diwy:: List (Heap ( pList )) —t Heap (pList) 
divvy Nil = £ 

divvy (Cons a e) = \Nit\ //a\ \Nif\ 

divvy (Cons a (l //b\ r)) 

| a^b = \Cons b r]//a\l 

| otherwise = \Consaf\//b\l 

The function fold divvy:: pList — > Heap (pList), selects the least 
element and divides the remaining list into two parts of balanced 
length (using Braun’s trick). The unfold of divvy constructs a heap 
by repeated selection, rather than by repeated insertion. This is 
rather reminiscent of selection and insertion sort, and is an intrigu¬ 
ing variant on building a heap. 

7.2 Phase Two: Sifting through a Heap 

Our natural transformation for describing one step of turning a 
heap into a list will take an interesting divergence from wither 
in Section 6.2. There, wither described one step of an in-order 
traversal. The search tree property provided the correct ordering for 
the output list, so no further comparisons were needed. The choice 
afforded to us by the heap property in Section 7.1 now means that 
further comparisons are needed, to obtain a sorted list. 

siftv.Heap (x x List x) —> List (x + Heapx) 
sift £ =Nil 

sift ((UMl) /M\ (r=-)) = Omsa(r.) 
sift ((l^_) Ha\ (r^NU)) = Cpnsa(U) 
sift ((U(Cons b l')) Ha\ (r- (Cons c /))) 

I b^c = Cons a (>(t )/b\ r)) 

| otherwise = Cons a (>(l //cXr 1 )) 

The fourth case is where these comparisons must be made: we need 
to pick the next minimum element from the left or the right. When 
constructing the heap node to continue with, we have the option to 
swap left with right, but this buys us nothing. 

Once again, we can routinely turn our natural transformation 
into a Heap-algebra and L/.st-coalgebra. This time we will start with 
the former as this is the algebra that matches the Heap-coalgebra, 
heaplns, that performs heap insertion. 

meld :: Heap (pHeap x List (pHeap)) 

Hi List (pHeap) 

meld £ = Nil 

meld ((l^Nil) //a\ (r^_)) - Cons a r 
meld ((l-J) //a\ (r-Nil)) = Cons a l 
meld((l-(Cpnsbl'))//a\(r-(Cpnscr J ))) 

= Cons a \l! //b\ r 1 
j otherwise = Cons a |7/c\ ft) 

We have called it meld as para meld:: pHeap —t List (pHeap) is 
a function one might find in a priority queue library, often called 
deleteMin. It returns the minimum element at the root and a new 
heap that is the melding of the left and right subheaps. This Heap- 
algebra is related to treesort’s Searc/i7>ee-algebra, shear, but due 
to the contrasting ordering schemes the mechanics of extracting the 
next element are quite different. 

The dual construction from sift is the Lwf-coalgebra that com¬ 
bines sorted lists; this time we will make a direct instantiation. 


Sorting with Bialgebras t 


2012/6/1 



blend :: Heap {v List x List (vList)) 

—» List (v List + Heap (v List )) 
blend e = Nil 

blend ((l^Nil) //a\ (r=: Jf| = Cons a (rm) 

Went/ ((/^_) //a\\ (r-M)) = Consa(lA 
blend (il A Cons b l')) lla\ (rA Cons c /))) 

I b^c = Cons a (>(l' //b\r)) 

| otherwise = Cons a (>(l//c\r f )) 

Note that apo (blend ■ map (id A out)) v.Heap (vList) —> v List is 
really a ternary version of merge, just as apo glue in Section 6.2 
was a ternary append. 

7.3 Putting Things Together 

In the previous two sections, we took the approach of defining the 
natural transformations upfront. The algebras and coalgebras are 
the synthetic results, so we will express the final algorithms in terms 
of these. Fully assembled, our heapsort is defined as: 
heapSort :: pList —»■ v List 

heapSort = unfold deleteMin ■ downcast ■ fold heaplnsert 
where deleteMin = para meld 
heaplnsert = apo heaplns 

We use the names deleteMin and heaplnsert to emphasise that this 
is exactly the expected algorithm for a function named heapSort. 

The dual to heapsort is a strange creature, for which we will 
invent the name minglesort: 

mingleSort :: pList v List 

mingleSort =fold (apo (blend ■ map (id A out))) 

■ downcast 

■ unfold (fold divvy) 

It uses the same intermediate data structure as heapsort, yet it 
behaves suspiciously like mergesort: the input list is recursively 
divided into two parts and then merged back together. This, of 
course is not quite true, as it actually divides into three parts: two 
lists of balanced length along with the minimum element. The 
merging phase is a similarly trimerous operation. 

The true mergesort is really described by another intermediate 
data structure: 

data Bush bush = Leaf K \ Fork bush bush 
A key facet of mergesort is that the first phase performs no com¬ 
parisons: the input is recursively uninterleaved, which matches the 
dimerous nature of Bush. Remember that quick (tree) sort only per¬ 
forms comparisons in the first phase, and that heapsort, and thus 
minglesort, do so in both phases. 

As minglesort impersonates mergesort, one would expect the 
dual of mergesort to be not unlike heapsort. It turns out that this is 
exactly the case; we have already continued this work and defined 
mergesort with Bush as the intermediate data structure and non¬ 
empty lists as the input and output data structure. 

data Listl listl = Single K \ Push K listl 
The non-empty list requirement comes from the fact that Bush is 
a non-empty container. For conciseness, we have not reported this 
work here. However, as a further justification that this is an intrigu¬ 
ing avenue for future work, we should point out that pBush is iso¬ 
morphic to (K,pHeap) —heaps (trees) paired with an additional 
element (Hinze and James 2010). It is also isomorphic to [pRose], 
lists of rose trees, where Rose is defined as: 
data Rose rose = Rose K [rose] 

Rose trees can be used to implement binomial trees, and the type 
[pRose] is exactly the type of binomial heaps. Given the character¬ 


istics of these heaps, this also begs the question of how we apply 
our approach to a heapsort where the first phase runs in linear time. 
We leave the study of the relationship between mergesort, heapsort, 
and the various data intermediate structures to future investigations. 


8. Related Work 

Sorting algorithms, described in great detail by Knuth (1998), are 
often used in the functional programming community as prime ex¬ 
amples of recursive morphisms. Recursive morphisms, known to 
be suitable for expressing many algorithms (Gibbons et al. 2001), 
have been widely studied (Gibbons 2003), especially ana- (Gib¬ 
bons and Jones 1998), cata- (Hutton 1999), and paramorphisms 
(Meertens 1992). Apomorphisms are less frequently used, but Vene 
and Uustalu (1998) provide a detailed account. 

Augusteijn (1999) presents the same sorting algorithms that we 
handle in this paper, but focuses on their implementation as hylo- 
morphisms. A hylomorphism encapsulates a fold after an unfold, 
combining a coalgebra A —> F A and an algebra F B —> B. The al¬ 
gebra and coalgebra have different carriers (A and B), but share the 
functor F. Their use has been explored in a wide variety of set¬ 
tings (Adamek et al. 2007; Capretta et al. 2006; Hinze et al. 2011; 
Meijer et al. 1991). However, we do not discuss hylomorphisms 
in this paper, instead using bialgebras, which combine an algebra 
F X —> X and a coalgebra X —> G X: they share the same carrier, but 
operate on different functors. Moreover, we focus our attention on 
the (co-)algebras being recursive morphisms themselves. Dually, 
Gibbons (2007) has explored metamorphisms, i.e., an unfold after 
a fold, in which they gave quicksort as a hylomorphism and heap- 
sort as a metamorphism as an example. We note that we obtain the 
same results with our approach but are also able to dualise each of 
these algorithms, yielding treesort as a metamorphism from quick¬ 
sort and mingleSort as a hylomorphism from heapsort for free. 

Others have looked at how to obtain “algorithms for free”, or 
develop programs calculationally. Bird (1996) give an account on 
formal derivation of sorting algorithms as folds and unfolds; Gib¬ 
bons (1996) derives mergesort from insertion sort using the third 
homomorphism theorem; Oliveira (2002) analyses which sorting 
algorithms arise by combining independently useful algebras. 

Our treatment of sorting algorithms as bialgebras and distribu¬ 
tive laws is an application of the theoretical work that originates 
from Turi and Plotkin’s mathematical operational semantics (Turi 
and Plotkin 1997). Hinze and James (2011) also use this work to 
characterise the uniqueness of systems of equations that describe 
streams and codata in general. The types in this paper that we call 
F + and G x are really the free pointed functor for F and the cofree 
copointed functor for G (Lenisa et al. 2000); our Sections 3 and 5, 
and Appendix A have lightweight presentations of results from Turi 
and Plotkin (1997) and Lenisa et al. (2000). 


9. Conclusion 

Folds and unfolds already gave some insights into the structure 
of sorting algorithms, and we leveraged this fact by using a type- 
driven approach to guide our derivations. By taking the analysis 
into the world of bialgebras, we were able to isolate the computa¬ 
tional essence of these sorting algorithms, which we read as dis¬ 
tributive laws. This allowed us to talk of equivalence between two 
algorithms. Furthermore, we could construct one algorithm from 
another this way, giving us algorithms for free. Even in such a pla¬ 
tonic domain, we were nevertheless able to address efficiency con¬ 
cerns, both algorithmically and by extending the theory to include 
para- and apomorphisms as more efficient recursion schemes. 
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A. Proofs 

In this appendix we will take swop :: List o List , -A List o List +, 
from Section 5 and show how to make it symmetric. We do this so 
that we can apply the general theory of bialgebras and distributive 
laws to construct the initial and final bialgebras. This will be in a 
similar fashion to the conclusion of Section 3, albeit now in a more 
expressive setting. Having given the general construction, we will 
show how apo- and paramorphisms are ‘shortcuts’. But first, we 
need to introduce a few definitions. 

A.l Casting 

Folds that consume a list of type pList require a LAf-algebra, but 
sometimes we will have a List + -algebra in our hands. We can cast 
the latter into the former with the following function: 

down + :: (Functor f) =>■ (f + a —> a) —> (f a —> a) 
down+ b = b- inr 

(In this appendix we will use ini and inr in place of ■ and ►, 
respectively, to better illustrate the duality with outl and outr.) We 
can also cast up: 

up + :: {Functor f) => (f a a) -A (f+ a a) 
up + a = id V a 

Dually, unfolds that produce a list of type v List require a List - 
coalgebra. Again, we can cast between the two: 

down x :: {Functor f) => (f x a -A a) -A {f o —>■ a) 
down x d = outr ■ d 

up x {Functorf) => (f a -A a) -A {f x a -A a) 

up x c = id Ac 

At a higher level of abstraction there is something deeper going 
on: there is an isomorphism between the category of Lwt-algebras 
and the category of LA/ + -algebras—dually for Lto-coalgebras and 
Ust x -coalgebras. The functors that witness these isomorphisms are 
subject to various coherence conditions, but the details are beyond 
the scope of this paper, see Hinze and James (2011). 

A.2 Symmetry 

In Section 5, swop has the type L o O x -A O cpqs* where List and 
List have been abbreviated to L and O, respectively. Given any 
natural transformation of type LoO x AOoL + ,we can construct 
a distributive law with the symmetric type L + oO x -A O x oL + . 
We will use the name swopsy for the symmetric law constructed 
from swop; the two are related by the following equivalence. 

up x c■ up + a = O x {up + a) ■ swopsy ■ L + {up x c ) 

c-a = O {up + a) ■ swop■ L {up x c) 

(Note that here we have used the name of the functor in place of 
map, so that we can be clear as to which map is being used.) We 
can read this equivalence as a specification for swopsy ; we shall 


also render it diagrammatically. 

l”i-+ x c) 

L X 

L {up x c) 

«P+ « L+ (O x X) 

1 ^ 
i 

L (O x X) 

^ l 

X swopsy <=$■ 


jswop 

«p x c O x (L + X) 

1 

; 

O (L+ X) 

[o^A^O* ( u ?+ a ) 

’ u- 

O X 

"0(«P+ a) 
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From this specification, the definition of swopsy can be calculated. 
Again, this calculation is beyond the scope of this paper, see Hinze 
and James (2011). We will simply state the final construction. 
In fact, as the distributive law goes from a coproduct (initial) to 
a product (final), there are two constructions, and, following the 
theme of this paper, they are equal by uniqueness. 

swopsy = L + outl A (O ini ■ outr V swop) 

= O x ini V ( inr • L outl A swop ) 

The following, regrettably detailed diagram, shows the initial 
and final swopsy-bi algebras. These are constructed in terms of folds 
and unfolds, which is why the terms are so complex: we need to 
mediate between L- and L + -algebras, and 0- and O x -coalgebras. 

unfold ( down x (swopsy - L + (up x out))) 

L+ (vO)-*- vO- up x out Ox (vO) 

A * A 


fold (down + (unfold ( down x (swopsy ■ L + (up x out))))) 
unfold ( down x (fold (down+ (O x (up + in) ■ swopsy)))) 


unfold ((O ini■ outr V swop) ■ L + (up x out)) ■ inr 
= { definition: L + / =/+ L/ } 

unfold ((O ini ■ outr V swop) ■ (up x out- 1- L (up x out))) ■ inr 
= { functor fusion: (/i V/ 2 ) • (gi + gf) =/t • gi V g 2 ■ gi } 

unfold (0 ini ■ outr ■ up x out V swop ■ L (up x out)) ■ inr 
= { definition of up x } 

unfold (0 ini ■ outr ■ (id A out) V swop ■ L (id A out)) ■ inr 
= { computation:/2 = outr - (/) A/2) } 

unfold (0 ini ■ out V swop ■ L (id A out)) ■ inr 
= { definition of apo as unfold } 

apo (swop ■ L (id A out)) 

A dual proof would show that para (0 (id V out) ■ swop) is equal to 
down x (fold (down + (0 X (up + in) ■ swopsy))). However, where 
apomorphisms offer a shortcut in both efficiency and brevity, 
paramorphisms only offer the latter. 


L+ (ML)- “P+ ->- ML-^ Ox GuL) 

fold (down+ (0 X (up + in) ■ swopsy)) 

It is worth comparing this diagram to the more simple diagram 
that concluded Section 3, which showed the initial and final swap- 
bialgebras. Where before we had in:: L (pi.) —> pL, we now have 
up_ in :: L + (juL) —> pL; and before we had unfold (swap ■ L out), 
but now we have unfold (down x (swopsy - L + (up x out))), and 
in the centre of the diagram, where we apply fold to it, we must 
use a final down- cast. Unfortunately, the selective but necessary 
use of casts makes the construction of the initial and final swopsy- 
bialgebras rather noisy. 

A.3 Apomorphisms as a Shortcut 

When we gave our final definition of insertion sort in Section 5, 
we wrote it as a fold of an apomorphism, rather than as a fold of 
an unfold. The reason for doing so was to utilise the computational 
efficiency of swop and apomorphisms—our insertion sort has lin¬ 
ear complexity in the best case. From a theory perspective, apo¬ 
morphisms also present a shortcut: we can use swop directly, rather 
than having to take the more general approach of constructing a dis¬ 
tributive law that is symmetric. This leads to more concise terms, 
compared to what we see in the diagram above. 

Paramorphisms and apomorphisms are useful in the case where 
we are building natural transformations involving F + and F x func¬ 
tors; the following is a proof that apo (swop ■ L (id A out)) is in¬ 
deed a ‘shortcut’ for our general construction of the final swopsy- 
bialgebra. 

down + (unfold (down x (swopsy - L + (up x out)))) 

{ definition of down + } 
unfold (down x (swopsy - L + (up x out))) ■ inr 
Ipt , { definition of down x } 

unfold (outr ■ swopsy ■ L+ (up x out)) ■ inr 
tsiii: { definition of swopsy } 

unfold (outr ■ (L + outl A (O ini ■ outr V swop)) ■ L + (up x out)) ■ inr 
S§|£ : { computation: f 2 = outr - (f\ A/2) } 
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